Think Business Analysts (BAs) and Test Engineers don’t need to collaborate? Think again.
Even in an Agile world, it isn’t uncommon for people in different roles to have limited interaction with each other, passing in the wind as projects progress.
Two roles that often suffer from this are Business Analysts (a role that isn’t even present in the official roles in an Agile methods scrum team), and Test Engineers.
They’re two roles that often bookend the software delivery life cycle, but that doesn’t mean that they don’t impact each other.
The Sailboat Retrospective: A Collaboration Catalyst
I recently ran a Sailboat Retrospective with our Test Engineers at Nimble. The aim? To discover ways the Business Analyst community can better support and enable our software testing team. This blog post delves into the key insights we gained.
Wind: How good BAs support and benefit Test Engineers
Consider Test from the start, by ensuring that you have the right level of information in User Stories – Ambiguity in requirements is not just the bane of coding, but of testing too.
So having clarity in User Stories before they are put to the delivery team is a must, but Test Engineers should be engaged in this early on as their interpretation of a requirement might differ from how an Engineer interprets the very same requirement.
One of the best ways to understand these different interpretations and to avoid ambiguity is via a 3 Amigos Session.
The role of 3 Amigos Sessions in clarifying requirements – If you’re not familiar with 3 Amigos Sessions, the idea is to bring a small group of people from the delivery team together, where their different perspectives can refine and drive clarity in a requirement.
When BAs are present in 3 Amigo Sessions, they can facilitate the discussion, walking through the business or product requirement. The inclusion of Test Engineers in these discussions is a necessity to understand what could possibly happen.
Ensure test effort is included when providing estimates on User Stories – Not strictly a BA role, BAs are often involved in facilitating Sprint Planning and similar sessions, presenting the User Stories to be estimated. Ensuring that test effort has been discussed and included helps to ensure that estimates are representative of the effort required for the entire story.
One example mentioned was a simple code change, but it had wide ranging implications which meant that the test effort was three times that of the code effort.
The importance of Bug triage and prioritisation – Again, not strictly a BA role, but by having both BAs and Test Engineers collaborating on this it helps to create a shared understanding.
BAs can develop their understanding of the issues identified by Test, helping them to consider Test more at the very start of a project and when a User Story is being formed. At the same time, bugs can be effectively documented and handled, and the Test Engineers have a greater understanding of the priority and context of the wider project.
Anchors: What BAs should not do for Test Engineers
The Pitfalls of Solutionising Requirements – A common pitfall early in a project is to solutionise the requirements instead of spending time understanding the problem that is being addressed. When requirements give specific solutions, defining the “how” rather than the “what”, Test Engineers don’t have the wider context of what the requirement is trying to achieve. This can lead to missed opportunities and edge cases in testing the solution.
Read more on boosting team engagement on our blog: Product Owners – boost team engagement and avoid micromanagement“
Poorly defined Acceptance Criteria are a bottleneck – As covered above under “Wind”, clear and detailed requirements can really help a Test Engineer. So at the same time, poorly defined and ambiguous Acceptance Criteria can slow the delivery of a User Story, or bring it to a halt.
Definitions of Ready can provide guidelines for a BA in writing requirements, but the best way to ensure the correct level of information is on a User Story is through regular and early engagement with the delivery team (including Test Engineers!). Good quality Acceptance Criteria (as suggested by our Nimble Test Engineers) include:
- Detailed KPIs
- Absolute statements, not questions
- Concise statements, not waffling
- A small number of criteria, not an extensive list
Inconsistent requirements are a challenge – When requirements and User Stories are captured in different styles, often by different BAs, this can lead to time spent translating requirements when they should be easily understood, no matter who picks them up. If there are multiple BAs working on a single project, they should work together to agree on a style and approach for the requirements.
Rocks: Risks and hazards that create obstacles for Test Engineers
User Stories that are too big – These are User Stories that are trying to deliver an entire system in one go without being broken down into smaller deliverable User Stories.
In theory, these kinds of stories should be broken down in Refinement and 3 Amigos Sessions, but a good BA should be able to bring “reasonably” sized user stories to those sessions so that they don’t need to be broken down too much. BAs won’t always get this right, but the best BAs learn from these sessions, responding to how the delivery team responds to the user stories they bring to the table.
Too much detail in User Stories is information overload – This differs from User Stories that are too big as they might be broken down into a deliverable increment, but they contain too much information that might not be relevant to the deliverable.
User Stories need to be easily understood by the delivery team, that means that they shouldn’t need to read several paragraphs to extract the relevant information. If this isn’t the case, key information could be missed, resulting in a deliverable that doesn’t meet the needs of the end user.
Not chasing answers to questions – In theory, any user story that is actively being worked on should not have any outstanding questions, but sometimes questions arise after work has been started. The problem here arises through a lack of support and prioritisation by BAs to unblock a user story’s progress across the board.
As a member of a delivery team, a BAs priority should follow that of the delivery team, meaning that work should be picked up from right to left, helping user stories to be moved to “done”.
Summary – Island
Not all of the points above are exclusive to how BAs can support and enable Test Engineers, but they certainly help to contribute to an ideal destination for the good ship “BA and Tester Collaboration”.
The key takeaways for effective communication between Business Analyst and Test Engineer
- High value communication
- Early engagement
- Clear and consistent requirements that do not solutionise
- Interestingly, whilst this was discussed in the retrospective, following a structure like Gherkin was not part of an ideal world. The consensus was that a consistent structure is needed, but if one structure doesn’t work, it shouldn’t be forced.
Author’s Bio
Greg Horsfall, Senior Business Analyst at Nimble Approach
Greg has over 10 years of IT delivery experience in a wide variety of industries. He has a passion for enabling delivery teams to realise and deliver real value, through effective communication, process adoption and leadership.
Photo credit to: Tima Miroshnichenko @ Pexels
